In the Internet connected environment, the Smart Device Clients including smart phone, tablet, eBook reader, notebook, PC and various smart gadgets are ubiquitous and omnipresent. Other than connectivity, one of the values of the Smart Device Clients is to be able to connect at any time and any place to retrieve services from one or many serving parties or servers. The services include audio, video contents, live or archived information, execution of applications, social media, messaging, email, storage, backup, calendar, contact, synchronization and others. There are different types of servers that serve these various requests from the Smart Device Clients. In general, these types of servers can be categorized to fall into two groups: a public cloud and a private cloud. Servers in the public cloud, implied by the name “public”, provide services that tend to be free with limited functionality or fee-based with more sophisticated services and interact with the public. Examples of the public cloud server include data center, social media services and storage/content provider through the Internet. On the other hand, servers in the private cloud tend to address the private need. The services provided are more private and personal as opposed to those offered by the public cloud.
One example of the application of the private cloud server is a private cloud storage server (PCSS). The PCSS sits within the local area network (LAN) managed by the user. It provides on-line and backup storage for the user either within the LAN or in the wide area network (WAN). The user is able to use a Smart Device Client to access information within the private cloud storage server at anytime from anywhere. The private cloud storage server and the associated Smart Device Client therefore form an example of the Private Cloud Server and Client architecture.
Conventionally, there are many storage server solutions exist, including network attached storage (NAS), Windows/Mac/Linux server, and direct attached storage (DAS) to fulfill the PCSS requirement. But the challenge for the Smart Device Clients in the field has been how to avoid the cumbersome setup and penetrate the firewall behind the router on the LAN to access the PCSS in a home or office environment. There are at least four kinds of solutions to this challenge.
One solution is to assign a fixed IP address and open certain ports for the router in front of the PCSS, such that the Smart Device Client is able to locate the PCSS from outside the LAN and to authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS.
The second solution applies when a fixed IP address is not available. The user configures the LAN router of the PCSS and open certain ports to map to the PCSS. The router is therefore able to be located by the intended Smart Device Client through a dynamic DNS (DDNS) service on the WAN. The Smart Device Client can authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS.
The third solution is to rely on another routing server in the WAN to conduct the virtual private network (VPN) communication between the Smart Device Client and the PCSS. The VPN communication allows the Smart Device Client to locate the PCSS, authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS.
The fourth solution is to rely on another routing server in the WAN to conduct the remote desktop protocol (RDP) or virtual network computing (VNC) communication between the Smart Device Client and the PCSS. The RDP/VNC communication allows the Smart Device Client to locate the PCSS, authenticate itself, penetrate the firewall and establish a secure communication channel with the PCSS. Other solutions can be mix-and match of the above mentioned solutions.
In the first scenario, a fixed IP address is required and the router needs to be set up and configured. The down side is that a fixed IP involves more cost and is usually not available in the home and small business environment. The router set up and configuration can be very complicated and are not user friendly with most consumers.
In the second scenario, a DDNS service is required and the router needs yet more complex set up. Again, the DDNS set up involves additional cost and complexity into the system. The router set up and configuration can be very complicated and is not user friendly with most consumers.
In the third and fourth scenarios, an outside routing server or service needs to be established, while a router set up is not necessary. The outside routing server or service controls and handles login/authentication between the Smart Device Client and the server. The private cloud becomes less private and less secure through the third party server or service. If for any reason the server or service is down, the communication and availability of the private cloud storage server will be jeopardized.
All of these scenarios require technical expertise that may be suitable for conventional corporate environment, but these scenarios are not suitable for consumer oriented Smart Device Client centric deployment.
In most conventional systems, an outside or third party routing server is used by the Smart Device Client during access to the Private Cloud Server. Using an outside server creates a number of concerns to the Smart Device Client owner. First, the sense of trust is always in question, because the outside or third party routing server is a middleman during all communication transactions between the Smart Device Client and the Private Cloud Server. It may hold all user account info, password and their corresponding IP addresses of the Smart Device Client and the Private Cloud Server. The routing server is able to sniff any communication in-between and render it insecure. Second, being an outside and third party routing server, its business model may not always be in-line or in-sync with the Smart Device Client owner. If the routing server is out of service due to any business reason, there is no remedy or option of replacement to restore the service. It potentially poses a tremendous business risk to the user, as the vital link in the communication can be broken without recourse.
What is needed in the consumer oriented environment is for the Smart Device Client in the WAN to be able to obtain services from a Private Cloud Storage Server (PCSS) or any Private Cloud Server (PCS) solving the following challenges:
1. Access the Private Cloud Server (PCS) at anytime from anywhere.
2. Access the PCS behind the firewall with fixed or dynamic IP address.
3. Require no outside or third party routing server in the WAN.
4. Require no additional router setup in the LAN.
5. Authenticate with the PCS using an authentication approach such as those of present invention including Initial Setup and Authentication Approach (FIG. 6) using a plurality of message boxes.
6. Establish a secure communication channel with the PCS.
If such challenges can be met and resolved, it will increase the deployment of the Private Cloud Server or service exponentially, due to the plug and play simplicity and availability. It also removes the technical and business concern by not utilizing a third party routing server. The Private Cloud Server covering storage and remote desktop service becomes very affordable and ubiquitous in the private cloud infrastructure. Accordingly, the present invention addresses such a need.